@coreyeng, please take a look at this.

I didn't get as far along with implementing what you need during my work on Origen Sim as I had thought I might.
However, I did think about it and fleshed out this vector format that I think will work well for you.

It will need you to take it and integrate it into the Origen generate command.

Here's how I envisage the integration going:

Add an "Origen" format tester driver. When enabled, this would hi-jack the pin drive, assert, don't care, etc. methods and the cycle method, and output to the file as required.
This is a bit more work than stepping in once the vector data has been constructed (as most current tester drivers do), but ultimately I think it makes the resultant patterns much more resilient to future application changes without putting any burden on the consumer side to do that.

Then update the generate command to support:

origen g my_pattern.org

That should be pretty simple and would just be a case of running it through a parser similar to the example contained in the RFC. i.e. just execute the supplied file verbatim with little or no involvement from the application at all apart from providing the DUT model.

@ginty looks good. It's very similar to how link transactions are encoded. Is there a mechanism to specify where the pin events take place (specify timeset)?

Thanks! Looks good to me. Seems like you're going for more compression over traditional vector based fine, which is good. I don't see any showstoppers for what I need to do.

I'm guessing if I get to the point that I want to use Verilog to ramload instead of the pins I could just pass in metadata on the pin (ramloading: true or something) that could disable it in the tester? Although that would kind of undermine use #2, I still like going through the entire process when using Windows based tools, as switching back and forth between Linux and Windows was incredibly error prone (and actually turned the team off to Origen for a minute until we came up with a plugin to automate the full generation process in Windows).

Thanks for working on this! For updating the generate command, I already need to do that for our current solution with the internal tools, so no concerns from me there.

Hi @pderouen, the intention would be to represent the timeset via a set_timeset operation rather than attaching it to every cycle.

To handle this (and other tester operations generally), I think we should change the record format from [pin_id, operation, *args] to [object, operation, *args], where the object is represented as a string that can be eval'd by the consumer to resolve the object to perform the operation on.

So, the example in the RFC would change to:

dut.pin(:tdi),drive,b1;3
dut.pin(:tdo),drive,b1;2
dut.pin(:tdo),drive,b0;dut.pin(:tdi),drive,b1;1
dut.pin(:tdi),drive,b0;10
dut.pin(:done),assert,b0;1
dut.pin(:porta),assert,b11110010;dut.pin(:portb),assert,hff5e;1
dut.pin(:reset),drive,b0;1

And a timeset change would just be:

tester,set_timeset,func,100;

The consumer would add an eval now like this:

File.open("my_pattern.org", "r") do |f|
  f.each_line do |line|
    *operations, cycles = *(line.split(';'))
    operations.each do |object, operation, args|
      eval(object).send(operation, *args)
      cycles.to_i.cycles
    end
  end
end

In principle, that should be able to represent any tester operation that is called.

Hi @coreyeng, on the point about passing in meta data on the pin, that's not really how this is intended to work.
The .org file is intended to be a static representation of a given pattern, like a .atp/.avc in that respect and will not support conditional logic.

So, if you wanted to have two variants of your pattern which handled a ram load differently, you would generate two .org files with the conditional switch being applied at the .org file generation time.

When it comes to re-playing the .org it will just execute exactly what is in the file with no options to deviate - i.e. it aims to be an exact representation of the pattern as it was when Origen generated it.
In fact, I expect that executing a .org will be much faster than executing the same pattern from source, since it completely bypasses all the application business logic.

Let me know if that doesn't make sense of if I've missed the point of your comment completely!

Oh yes, I wasn't implying actually putting it into the pattern, more as to how the tester would handle it from the app. I think from an application perspective, I could pass in an option to the pins as to whether or not its ramloading, and the tester would pick to write ramloading pins or not based on a command-line option from the origen g command.

@ginty sorry am late to the party. Forgive the brain dump this morning:

• Minor typo in RFCS text 'repetive'
• Does it make sense to have an alias for 'assert' and 'drive' ? Like 'A', 'D', just to compress files a little more
• Perhaps a different delimiter than ';' for between a series of records/operations and the cycle #. Suggest '@' ?
• Would variable values be allowed for the data argument? Or is it that because this is an intermediary format that user wouldn't really need/want to store variables here? What about symbols? (thinking in terms of 93k where the values mean physical wave descriptions and not necessary logical values of 1 or 0.)
• How are subroutines handled? labels? Again, not necessary due to the intent of *.org to be more straight-line type vectoring (no loops or other 'opcodes' either). If so might be good to explicitly state that. I could see the use for block code (basically subroutines) where you might want to have another *.org called from within another, but it does complicate things (pin state across the transition)

Thanks for the review @redxeth, comments on your points:

• Does it make sense to have an alias for 'assert' and 'drive' ? Like 'A', 'D', just to compress files a little more

Possible, but not something I really plan to pursue right now - I think these will already be significantly smaller than their equivalent typical ATE representation.
To do this, we would need to make pin.a and pin.d methods as aliases of the existing methods, then add something to the capture logic to recognise that a shorter alias is available whenever an application calls pin.drive. I don't particularly want to add much complication to the capture system and would prefer to keep it simple and have it just record what the application actually calls.

• Perhaps a different delimiter than ';' for between a series of records/operations and the cycle #. Suggest '@' ?

I can't think of a scenario where the current delimiter wouldn't work, and is more conventional/pleasing to the eye IMHO.

• Would variable values be allowed for the data argument? Or is it that because this is an intermediary format that user wouldn't really need/want to store variables here? What about symbols? (thinking in terms of 93k where the values mean physical wave descriptions and not necessary logical values of 1 or 0.)

Variables would all be resolved at the level that this is captured. This is a record of what actually happens on the pins, not any kind of record of what the application did to achieve that. e.g. if the application calls pin(:my_pin).drive(dut.pin_x_val) then what gets recorded here will be whatever dut.pin_x_val resolves to. That can be any literal value, so if what gets sent to the pin is a 0, 1, 'x' or whatever, that will be accurately reflected in the org file.

• How are subroutines handled? labels? Again, not necessary due to the intent of *.org to be more straight-line type vectoring (no loops or other 'opcodes' either). If so might be good to explicitly state that. I could see the use for block code (basically subroutines) where you might want to have another *.org called from within another, but it does complicate things (pin state across the transition)

In principle sub-routines should be handled OK I think, e.g. if the application calls tester.call_subroutine(:blah) then that would be reflected in the log file. Like the equivalent ATE pattern, that would likely not actually contain the subroutine itself, so it would probably be of limited use to re-play a pattern like that as an org file.

Ok, @ginty. Might help to clarify this stuff in the original RFCS text file -- to say how this file IS and IS NOT meant to be used.

Don't agree on the cycle count delimiter BTW ;-) but won't belabor it.

(To my eye something like porta,assert,b11110010;portb,assert,hff5e;1 doesn't clook as clean as porta,assert,b11110010;portb,assert,hff5e;@1 or something to help make the cycle count stand out.)

Also, rereading my comment above I realize I forgot to add something else. In dealing with v93k you realize that '0', '1', 'X', 'H', 'L' are meaningless as they are not 'values' in the traditional logical sense, but waveform indices. So you can have also '2', '3', 'X', 'Y', 'Z', whatever. The timeset defining the waveform table then becomes very important to what the pin really sees in the digital world.

Will this tester-agnostic format be able to handle the 'value' being driven to be something with more than 1 or 2 edges? If so how will ports be handled (since hex values are digital in nature). Or would a multi-edge cycle have to get broken out so that it appears to be single-edged? (not really something you want to have to do).

Just dont want to limit ourselves in terms of the Teradyne way of thinking.

Hi @redxeth,

Origen already supports pin(:x).drive('3') for the V93K and any literal value in the arguments would be output verbatim to the org file. So that would work fine, though the org file would not be tester agnostic in that case, but that's OK.

The same would be true when applying values to pin groups, however Origen doesn't really support that yet. If and when it does though, the org file would support it. The org file is nothing more than a capture of objects (pins and the tester mainly), and the methods and arguments that are called on them.

It has absolutely no understanding about what any of it means, it is just a record of what sequence of operations were performed on the tracked objects, allowing that same sequence to be replayed later without having to go through the application logic that created the sequence in the first place.
With the understanding that the org file is simply a record of what methods/args were called, then it will implicitly fully support any method/arg combination that Origen does.

Ok, thanks @ginty .